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[57] 



ABSTRACT 



In teleconununications switching systems, software is 
frequently modified, enhanced or replaced altogether 
by new versions. The implementation or integration of 
the new or revised software into the operational system 
must be accomplished in accordance with strict require- 
ments for not disturbing the ongoing activities of the 
system. Therefore, itiis|g^iiabl|^tha|jLt^^ 
halt^ll ^uleithejfeha aigegtoiithe^^^ 
Rather, the preferred approach is to be able to replace 
software modules with new versions on the fly, during 
system operation. The smooth modification made possi- 
ble in the disclosed system allows such changes with 
minimal disturbance to ongoing activities byfdynami- 
'^ylln^^g anj^tojdin^ 

oitibB. Tie disclosed system accomplishes this by ap- 
plying expanded object-oriented programming tech- 
niques and utilizing language-independent interface 
specifications that remain unchanged and that obviate 
the need for storing symbolic information that would be 
subject to change following modification. 

35 Claims, 5 Drawing Sheets 
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public: 
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private: 
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ossure compatibility 
i: 

closs X{ 
privote: 
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public: 

create(int size) 
|p=C_X:.-Create(size):| 
void Mx(int doto); 
~X0 
{delete p;j 
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interface with all of the other software blocks that form 

SYSTEM FOR DYNAMIC RUN-TIME BINDING OF a part of an operational SPC switching system. In addi- 

SOFTWARE MODlJLESm A COMPUTER tion, telecommunications switching systems are virtu- 

SYSTEM jjiy ^^ygj. operation. Ideally, these systems 

T» * ^Tr^T> ^TT^TTx ^T, x^T, r«^,^»«*, ^ would vxcL pcrpetually, without interruption because of 

BACKGROUND OF THE INVENTION ^he contin^r need for communi^tions services 

A portion of the disclosure of this patent document within a community. That is, there is a continuous flow 

contains material which is subject to copyright protec- of telecommunications traffic being processed through 

tion. The copyright owner has no objection to the fao- the system even at off hours of the day or night and any 

simile reproduction by anyone of the patent document interruption in the operation of the switch results in a 

or the patent disclosure, as it appears in the patent and disruption of that telecommunications traffic. Such a 

trademark office, patent file or records, but otherwise disruption could be extremely damaging to the system's 

reserves all copyrights whatsoever. operation and its effectiveness, as weU as to its acccp- 

FIELD OF THE INVENTION 15 among users or customers of the system. 

_ . . , , ^ These real-time requirements of telecommunications 

The mvention relate to the modification of software, switching exchanges place severe constraints on both 

and m particular, to the replacement of software m an the testing of enhanced vemons of the software, or 

opeiatmg computer sys^ havmg both old and new ^ions thereof, containing new or improved function- 

versions of modified software coexistme m the com- n i_ /-el 

puter and simultaneously executable therd^ 20 ^eU »s the substifiition o software «nt^ 

*^ ' error corrections or "bug fixes" mto the switch without 

DESCRIPTION OF RBLATED ART disrupting existing telecommunications uaffTic being 

The system of the present invention, a linked proce- V^occsscd by the switch. Therefore, integrating new 

dure call mechanism for dynamically binding scpiately versions of software components or umts mto the sys- 

and simultaneously executable versions of software 25 tem usmg the traditional "edit-compile-link-load-run" 

during Operation of a computing system to aUow trans- approach is not desirable. What is preferred is a method 

parent, uninterrupted updating of software, can best be provides the capability to modify or extend the 

understood by reference to the larger problem of incor- software while the system is in operation, without the 

porating modified software into an operating computer downtime. 

system. One aspect of computer software is that it must 30 Attempts have been made to solve the problems asso- 
be periodically updated with revisions, additions and/or ciated with incorporating new software into operating 
deletions in order to continue to provide adequate func- computer systems. For example, some advanced on-line 
tionality to the user, to optimize the software and to operational systems in use today that do not operate in 
correct errors and discrepancies that arise throughout a stand-alone or batch fashion solve the problem of 
the life of the software. As new features are added to 35 replacing old software in a manner that clearly differs 
software, it is desirable to replace the old software with from the method used with stand-alone or batch sys- 
the new versions as early and as easily as possible in tcms. However, such systems still replace software 
order to provide the user with the features of the new manually, although more transparentiy than in stand- 
software, alone systems, by requiring that individual users or user 
In certain types of computing systems, such as stand- 40 groups actively select whether or not to process using 
alone or batch processmg systems, changing software the new or revised version of the software. This option 
from one version to anotiier presents few obstacles. may be exercised by users by modifying the concatena- 
TypicaUy, tiie comput^ system is merely diut down tion of software to be utilized by processes operating 
aurmg a penod ot the day when there is httie activity ^^ler their individual user-id. The option remains avail- 

^^^.^"^ T^f''- 7?' to d-ri^g a ^ period time, usually mea- 

old software is then simply removed and replaced bv j • i ^-l • i.- *^ r. 

the newer version of the Lftware. Tliereafte^the toZ '^^."^ ^"""^ ormontiis, m which tmie the software 

puting system is restarted and all fiiture data processing ^'^''1'^^'^ ^^^^^ 

is done with tiie new version of the software TTiis prc^ after successfully operatmg at each poor level without 
cedure, of course, assumes that tiic new software has 50 dfcrepanci^. Upon reaching the top level of the 
been adequately tested and debugged on an offline sys- ^o^^at^iation, the software is declared "operational" 
tem to the point that the software personnel and the ^^^^^ versions are no longer available to users of the 
operational management are confident that it will ade- system. Insertion of new software mto the system, as 
quately perform the fimctions for which it is intended ^ migration up the various levels, is controUed 
witiiout undue interruptions that may require halting 55 * process of configuration management— a manual 
and then re-starting the entire computing system, process of reporting, approval, tracking software ver- 
In other types of con^juting systems, such as modern ^^^^ ^^^^ ^d implementing approved changes, 
stored program control (SPC) telecommunications ex- ^ methods used to update software on 
change systems (commonly referred to in the industry batch or stand-alone systems, there are well known 
simply as "switches"), neither the testing of new ver- 60 drawbacks to incorporating new or modified software 
sions of software nor the changing of software in the i^^o a system in this fashion. It is largely a manual, labor 
system is as easy as in standidone batch processing sys- intensive system that is complex and time consuming. It 
terns. For example, new versions of software cannot be leaves control over whether and in what cases the sys- 
cffectively tested without being placed into actual oper- tem will operate with certain new software to the users 
ation processing calls. The software must be tested 65 with no means of performing gradual, restricted, on-line 
while in operation in order to determine whether the use so that errors do not proliferate or immediately 
software will adequately function under live operating affect all ongoing operations. The method of control- 
conditions and whether the new portions will properly ling access to new or revised software is directiy linked 
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and limited to the individual user executing the soft- 
ware. 

In the typical telecommunications system in use to- 
day, the problem of changing software or portions of 
software is even more severe. Although such systems 5 
cannot properly be called batch or stand-alone systems* 
their operation must also be halted whenever a software 
change is made. The new software is then loaded and 
the data, along with the old software, is transported to 
the new software. During the time when this transport 10 
is occurring, the system is completely out of operation. 
This period can last as long as an hour, making it neces- 
sary to schedule software changes for off-peak hours of 
operation. Even so, an hour of downtime in a telecom- 
munications switching system is a very long and costly 13 
period because no calls can be processed during this 
time and any needs for emergency communications 
during this period cannot be serviced. 

The problem of changing software during execution 
within a computing system becomes more complicated 20 
when all or a part of the software requires linking. Ordi- 
narily, in such systems, separate portions of the soft- 
ware must be developed and re-compiled separately. 
Then all the portions that interoperate must be relinked 
for execution. It is also necessary to create and TttflinteiTi 25 
symbol tables that provide information for all external 
symbols used throughout the software. The linking 
process creates the information for storage in the table 
and identifies any unresolved references. When a por- 
tion of the software is modified, for any reason, the 30 
symbol information is likely to become changed as well. 
Therefore, any symbol information remaining in mem- 
ory must be removed or it will bring about errors in 
processing caused by incorrect symbolic referencing. 

One system, disclosed in U.S. patent application Ser. 35 
No. 07/907,294, filed Jul. 1, 1992 in the name of Nilsson 
et al, entitled "Changing Software During Computer 
Operations," and assigned to Tdefonaktiebolaget L M 
Ericsson, hereby incorporated by reference herein, 
describes a system and method to overcome some of the 40 
limitations in changing software "on the fly." That 
system provides for the installation of new software into 
the stores of the telecommunications system along with, 
and in addition to, the old software. In that system, 
existing traffic in the computer system is initially pro- 45 
cessed by the old software and test traffic is routed 
through the switch for processing by the new software. 
Thereafter, if the test traffic is handled successfully by 
the new software, a portion of the actual live traffic is 
selectively routed through the new software with the 50 
live traffic still being handled by the old software. 
Should the sample traffic be carried adequately by the 
new software, all of the traffic is switched to the new 
software. As soon as the processing of all calls being 
handled by the old software has been completed, the 55 
old software is no longer utilized by the system and may 
be removed. 

That disclosed system provides for smooth verifica- 
tion of new or modified software. It allows data to flow 
through the new software in a gradual and controlled 60 
manner, yet as part of the live operational system. The 
system provides for early detection of errors and dis- 
crepancies with little or no impact to actual operation of 
a telecommunications switching system because the 
initial data routed to the new software is only test data 65 
generated by the system. If, in processing test data, the 
telecommunications system detects an error, no further 
traffic is directed to the new software so that, even if the 



new software had been processing actual data, distur- 
bance to the overall trafBc of the system is minimized. 

This disclosed system also redirects traffic from the 
old software to the new software in a gradual manner. 
The disclosed system includes the capability to allow 
transactions that began processing with the old soft- 
ware to complete its processing using only the old soft- 
ware. Only transactions that began subsequent to the 
installation of the new software will be processed by the 
new software. This aspect of the disclosed system re- 
sults in only a minimal disturbance to users during a 
transition phase from certain old software to its replace- 
ment by or augmentation with new software. Further, 
this aspect minimizes the amount of data requiring con- 
version for and/or transfer to a different set of software 
than that with which it was initially processed. 

Other attempts to solve at least some of the problems 
associated with updating software in operational com- 
puter systems have focused on different aspects repre- 
senting only a portion of the overall problem, in par- 
ticular,the linking issue. For example, in U.S. patent 
application Ser. No. 734,456, filed on Jul. 19, 1991, 
containing an invention by Anders Abrahamsson and 
Lars Hohnqvist and assigned to Telefonaktiebolaget L 
M Ericsson, there is disclosed a system for dynamically 
linking software during run-time. That system, how- 
ever, involves a complex system of indirect addressing 
that requires use of either a specialized or extended 
operating system and/or a special con^jiler. That sys- 
tem has several other limitations, including the need for 
a non-standard operating system. Further, this system 
will not work with standard applications software. 

Other related art has been discussed in various publi- 
cations. For example, the article entitled "Future Docu- 
ments" published in BYTE MAGAZINE relates to 
object linking and embedding while U.S. Pat No. 
4,791,550 to Stevenson et al relates to link pointers and 
U.S. Pat. No. 4,667,546 to Freeman et al deals with 
intrusion into unguarded regions of memory. None of 
these references discloses solutions to the problems 
discussed above. 

Therefore, it would be highly useful within the tele- 
communications industry to be able to efficiently per- 
form dynamic runtime linking between separately 
loaded program units in a computer system. The system 
of the present invention provides such a method. 

SUMMARY OF THE INVENTION 

The system of the present invention comprises a sys- 
tem for dynamicaUy binding software modules between 
two or more separately loadable software applications. 
This aspect of ihe system of the present invention em- 
bodies the inventive combination of a linked procedure 
call mechanism with the capability to perform dynamic 
runtime binding between separately loadable program 
units in a computing system. 

In one aspect, the system of the present invention 
comprises a linked procedure call mechanism that em- 
bodies a trader within the operating system kernel to 
enable an interface between different software units. 
This linked procedure call mechanism is also used to 
effect the inter-linking and binding of old and new soft- 
ware units during runtime. In employing this linked 
procedure call mechanism in the system of the present 
invention, the necessary interface specification is cre- 
ated utilizing another aspect of the system of the present 
invention, a specialized language referred to as an ob- 
ject-oriented interface description language (ELIN) as 



06/03/2004, EAST Version: 1.4.1 



5,339,430 

5 6 

disclosed in U.S. patent application Ser. No. FIGS. lA-lB are diagrammatic illustrations of a prior 
07/907,293, filed on JuL 1, 1992 in the name of Lundin art system for controlling the introduction of new or 
et al and assigned to Telefonaktiebolaget L M Ericsson, modified software to an operational software system; 
hereby incorporated by reference herein. This language FIG. 2 is a diagrammatic representation of the man- 
contains special constructs specially designed for the ^ ^ which software blocks may be dynamically 
development of interfaces for the liiied procedure call linked in accordance with the invention of an above- 
aspect of the system of the present invention. Because referenced co-pending application; 
these interface specifications contain attributes sup- ^ ^ ^ illustrating the process of 
ported by an object-oriented paradigm, polymorphism changing software during runtime in accordance with 
and dynamic binding of objects having a common base invention of the above-reference co-pending appli- 
interface specification can be readily achieved. cation entided, "Changing Software During Computer 

In another aspect, the system of the present invention O^ratic^ns"; 
comprises a mechanism by which program units may be * * ^^^^ diagram illustrating the manner in 
constructed and later modified separately in a running ^^^^ operations arc addressed within the soft- 
system witiiout causing any disturbance to the ongoing system of the pr<^t invention; 
operations of the computing or telecommunicatioi^ ^J^^ ^^"^ illustrating the mamier m 
system in which it opeiitcs. According to this aspect, ^^<'^ ^^^^^ ^ addressed withm tiie system of the 
the program units are constructed and compiled sepa- myention; , ^ ^, 
rately using a language-independent interface spec^. 5^?' ^Jf ' ^^^^^^^T ^^^^^ the i^er m 
tion. HiisLpect^ws pr^ units to be ^ which software <^ be addressed by m^ 

I. * J - J J ^1 1 system of the present invention; 

and changed md^dently so long as die mterfaces pio. 7 is an illustotive diagram of the mamier in 

remam unaltered, ^lus aspect of the system of the pres- ^^^^ ^ ^^ject oriented interf^escription language 

ent invennon provides the added advantage of ehmmat- ^ to implement the system of the present bven- 

mg the need to store symbol mformation for use m 25 tion; and 

linking since the binding occurs at runtime. FIG. 8 is a chart illustrating certain aspects of the 

In yet anotiicr aspect of the system of die present system of the present invention, 
invention, linked procedure call (LPC) objects are cre- 
ated and manipulated in a manner simil ar to that of DETAILED DESCRIPTION 
objects of local classes in an object-oriented paradigm. 30 The system of the present invention utilizes, in some 
This aspect of the linked procedure call mechanism is aspects, principles of object-oriented programming, 
transparent to the programmers of the system. The Object-oriented programming involves essentially four 
transparency is achieved, in this aspect of the system of dements: classes, objects, instance variables (or data 
the present invention, through the automatic generation members as implemented in C4-+), and methods (or 
of code that performs the runtime binding in accor- 35 member ftmctions in C-f+). A class is simply a tem- 
dance with the interface specification. This aspect of the plate used to define objects, which are instances of the 
present invention provides the advantage that standard class they are created from. Classes have two types of 
language compilers may be used, without requiring any components; instance variables and methods. Instance 
extensions and without the need to modify the LPC variables serve as data elements and methods serve as 
model. 40 functions, i.e. they defme an object^s behavior. Instance 
In still another aspect, the system of the present in- variables and methods can be combined in a single com- 
vention comprises a set of direction points used to dy- object in execution time. That is, an object encap- 
namically direct transactions (also referred to as sulates an instance of the variables which can be manip- 
*^cads" or "chains of events") within the operational combined methods. Hence, pro- 
system to either new or old versions of a modified soft- grammmg is performed with a focus on objects, rather 
ware unit. The system accomplishes the dynamic direc- functions or tasks to be performed, 
tion through a number of means, including analysis of Certain techniques of object-oriented programming, 
messages addressed by function title, which makes it m the art, are incorporated into the system 
possible to direct messages to either a process executing , of the present invention in the preferred implementation 
anewvei^onofasoftwareunitortoaprocessexecut- ^ of the system of the prew^nt mvention m tiie pro^^ 
ing an old version. Another type of direction point is ^+ +■ ^""f techmqu« mclude inhen- 
dynamic run-time binding (e.g., hnked procediie call) PO^^an^^l^f^ encapsulation. Inhentance 

between software units which nLikes it possible within a '^'^^f ^ If^'^.w'^ f 

* ««i--^v»ii-t~ixuuic wiu^a SO that code is easily reusable, so that data and code can 

process to execute 55 ^ ^ ^^J^^ ^^^^ ^ ^ 

' .„ , • . J . * ^. altered, without having to change the existing class. 

As ^ be r««my appreciated by those of ordinary Polymorphism is the property that provides the ability 

skiU m this particular art, tiie pnnciples and aspects of to use different types of objects in the same way because 

this mvenuon could also be utihzed to advantage the the different object types share a common interface, 

runtime conversion ofsoftware ma variety of computer 60 Inheritance of interfaces is the property that makes it 

apphcations other than telecommunications switching possible to derive other object types from a common 

systems. denominator. Finally, enc^ulation is a technique for 

BRIEF DESCRIPTION OF THE DRAWINGS combining the data and operations needed to process 

the data all under one "roof." It further allows the capa- 

For an imderstanding of the present invention and for 65 bility to protect the data from excessive or unnecessary 
further objects and advantages thereof, reference can access and to hide the details of the data organization, 
now be had to the following description, taken in con- Referring first to FIG. LA, there is illustrated a soft- 
junction with the accompanymg drawings in which: ware control scheme utilized in a prior art system for 



06/03/2004, EAST Version: 1.4.1 



5,339,430 

managing the introduction of new or modified software FIG. IB illustrates the human process of configura- 
mto an operational software system. FIG. lA iUustrates tion control that is imposed upon the software Ubrary 
a hierarchical set of software levels, the contents of hierarchy illustrated in FIG. lA in order to maintain 
each of which is controlled by the members of a review control over both the baseline and the new or modified 
board. All changes to the software must be approved by 5 software being introduced to the system on a daily basis, 
this board prior to such changes being implemented in As noted above, the new software enters the hierarchy 
the system. No software will be integrated into the at the lowest appropriate change level following ap- 
system until the review board makes a formal determi- proval by the review board. If the new software results 
nation that the software is needed, that it has been ade- in errors or discrepancies, the software is removed from 
quately tested and that it is not likely to cause damage 10 the hierarchy and returned for additional software 
or mterruption to the system. mamtenance work as at 6. Once the problems have been 

The hierarchy of levels may be composed of several corrected and the software has been retested, it may 
separate hierarchies linked together by an individual once again, upon board approval, be integrated into the 
user who has access to and need for those levels or system at the lowest change level. If no problems are 
•Tibranes" of software to perform his or her function. 15 detected within the fixed period allowed, the software 
At the top of the hierarchy 1 is the real-time, opera- will automatically migrate to the next level unless the 
tional software that is typically most widely used and next level requires another board approval as at 7. Oth- 
most stricUy controUed ("AB.D"). Below this level is a erwise, it wiU migrate on a fixed schedule after having 
change library 2, designated by the additional letter C in been properly approved. This process will continue to 
the suffix ("AB.DC"). Lower levels of operational soft- 20 be repeated until the software reaches the highest level 
ware withm the hierarchy may belong to different in that portion of the hierarchy at which time it will be 
groups of users within the system and will be controlled declared fiiUy operational software, 
by review boards at those levels. New or modified real- Referring next to FIG. 2, there is shown a diagram- 
time software «iters the system, after approval, at the matic representation of the transfer of software signal 
lowest appropriate change level, i.e., a level that ends 25 information within a modular software system m accor- 
with the letter C as at 2 and 3. dance with a previously disclosed invention. A block of 

Once new or modified software enters tiie system, it modular software 11, referred to as block A, comprises 
remains at the entry level until a specified period has the plurality of sections including program code listing 
passed and the software has produced no detectable portion 12, a signal distribution table 13 and a software 
errors. It wiU then migrate to the next highest level. In 30 signal sending table 14. In addition, a job buffer 15 
some cases, tiiis will require advance approval by a comprises a plurality of registers 16 within which is 
specified review board; in other cases the migration wiU temporarily stored software signals awaiting processing 
occur automatically, as part of a regularly scheduled by the central processor necessary to forward those 
system activity. The migrations are transparent to the signals to a requesting block of software, for example, 
users and the software will be available immediately 35 Another software block, Block B 17, also includes a 
upon migration or entry to the hierarchy to users who program code listing portion 18 and a signal distribution 
have structured their software concatenation to access table 19. The represented embodiment of the invention 
software in the libraries containing the new or changed also includes a global signal distribution table 20 within 
software. which there is maintained a listing of all of the local 

As also illustrated in FIG. lA, the same process may 40 signal numbers for the particular signals contained in 
be repeated and occurring simultaneously for non-real- each block of software loaded in the system, 
time engineering type software that resides within the As discussed briefly above, the global signal distribu- 
same system. The only difference in this case is that the tion table 20 is an essential element of Tnamtaining the 
control process is managed by a different set of people linkage addresses among different modules of software, 
and the process may not be as rigorous as that for opera- 45 The global signal distribution table 20 maintains the 
tional software used generally throughout the system cross-references between the global signal numbers 
for critical processes. The integration of the software corresponding to particular signals being sent from one 
occurs in the same manner for this engineering software module or block to another and the local signal numbers 
as with operational software, however. The new or corresponding to each of those signals within each indi- 
modified software enters the hierarchy at the lowest 50 vidual block in the system. When a block of software is 
appropriate change level as designated by a C as the last loaded into the system, the portion of the global signal 
letter in the suffix, as at 4. It then migrates in an upward distribution table 20 corresponding to that block is re- 
direction over time, with the necessary approvals, until written to include a local signal number for each signal 
it reaches the top 5 of its portion of the hierarchy. With which is included within the block of software. This is 
either engineering or operational software, once it has 55 conventionally done by combining the global signal 
migrated to the next level it no longer resides at the number of that particular signal with the block number 
lower level. of the software block containing that signal through an 

The decision whether to utilize the new or modified exclusive-or process or some other technique of com- 
software entered into the system's hierarchical libraries bining. Thus, when a software block is removed from 
is left to the individual user or user group. The user(s) 60 the system, modified or enhanced in some way that 
may select which levels of the libraries the system is to results in changes to the individiial signals within the 
use in concatenating software for their use. They may block, that portion of the software signal distribution 
choose to bypass lower levels of software altogether or table must be rewritten to reflect the new content of 
they may simply choose to avoid the lowest change signals within the block and a new calculation of local 
level which contains the newest and least tested soft- 65 signals numbers for each of those signals within the 
ware. The highest level of each portion of the hierar- block. 

chy, of course, contains the bulk of the in-use opera- As further illustrated in FIG. 2, a software signal SI 
tional software. is being sent from block A 1 to block B 17. Block B 17 
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is referred to as the receiving block, while block A 11 is 
referred to as the sending block. The block number of 
the receiving block is also referred to as the BNR. The 
system is to send the desired signal SI to the receiving 
block and first obtain the global signal number for signal 5 
SI by accessing the signal sending table 14 of block A 
11 by means of its address comprising the program start 
address of block A 11 (PSA^) plus the value of the 
signal sending pointer (SSP). Qnoe the global signal 
number for SI is obtained, it is loaded directly into a 10 
register 16 within job buffer 15 and awaits transfer to 
block B in accordance with the priority protocob of the 
central processing unit and the priority assigned to the 
particular signal being transfenel During this time, the 
information was retained in the form of the global signal IS 
number of SI and the block number of the receiving 
block. As soon as the signal transfer operation has risen 
to a sufficient level of priority for the transfer to be 
executed, the system accesses die global signal distribu- 
tion table 20 to obtain the local signal number of SI in 20 
block B 17. This is accomplished by entering the global 
signal distribution table 20 with the address found by 
taking the global signal number and exclusive-oring that 
value with the block number BNR. Within this table at 
that address is found the local signal number for SI in 25 
Block B 17, the receiving blocL 

Once the local signal number for SI in block B 17 is 
obtained, the system then enters block B 17 by locating 
the instruction address, lA 21, within block B 17 where 
the signal should be entered. This is done by obtaining 30 
from the signal distribution table 19 of block B 17 by 
taking the program start address of block B 17, (PSAj) 
minus the local signal number within block B 17 to read 
the instruction address 21. Once the instruction address 
21 is obtained, the signal SI is entered into block B 17 35 
and the transfer is complete. Thereafter, the instruction 
located at the lA 21 begins execution. 

One point must be kept in mind in connection with 
the application of this disclosed system. When modify- 
ing code affecting a signal entry point in a block, it must 40 
be kept in mind that if the data structures are modified, 
calls of that new or modified code may reach old pa- 
rameter values, e.g., signal data accompanying the sig- 
nal in the job bu£fer that contain addresses and or data 
in the format of the data structure that was utilized 45 
before modification. On the other hand, however, if the 
block at the time of reloading the newly modified soft- 
ware block has return addresses, the local signal num- 
bers on the return address stack that have been modified 
as between the old and new versions are updated by the 50 
operating system. 

Referring next to FIG. 3, there is shown a flow chart 
illustratmg the smooth modification method of transi- 
tion &om an old software version to a new software 
version. In particular, the system presupposes that exist- 55 
ing software is actively nmning in the system and begins 
at 30, with the loading of a new versions of the software 
into memory. At 32, the system copies the data with its 
changes in the new version, and links it to the new 
software. At 34, the system begins to run test calls with 60 
the new software and normal traffic continues to run 
within the system with the old software and the old 
data. At 36, the system queries "does the new software 
work on the test traffic?" If not, the system moves to 38 
at which point the new software and database is re- 65 
moved from the system and the procedure ends at 40. If 
the new software does work on the test traffic at 36, the 
system moves to 42, at which point it runs samples of 
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actual traffic with the new software while maintaining 
the remainder of the normal traffic along with the old 
software and old data. Next, at 44, the system again 
queries whether or not the new software is working on 
the sample traffic. If not, the system moves to 38, and 
the new software and database are removed to end the 
process. If, however, the new software is processing 
sample traffic successfully at 44, the system moves to 
run all future calls with the new software and the data 
at 46. Thereafter, at 48, the system again queries 
whether or not the new software is working and if not, 
moves to 38 to remove the new software and end at 40. 
If the new software is working on running the normal 
traffic in the system at 48, the system queries whether 
all the old calls have yet been complet^ or not within 
the system at 50, and if not, queries if the time limit for 
the diange has expired at 54 and if not continues to: (1) 
nm all new calls with the new software, and (2) run all 
old calls with the old software at 46 until a yes is re- 
ceived at 50 or the time limit has expired at 54. If the 
time limit has expired at 54, the system terminates or 
transfers all remaining calls to the new software at 56 
and moves to 52, Thereafter, the system moves to 52 
and the old software is removed along with the old data, 
and the system has made a switch during runtime from 
old software to new software without unduly endanger- 
ing or delaying existing traffic within the teleconmiimi- 
cations switch. 

In effecting the linking of individual calls to different 
blocks of software, such as in the example where new 
telecommunications processing software if first tested 
with test calls before normal calls are redirected from 
the old software to the new, the system of the present 
invention may be visualized as containing a Call Identi- 
fication (ID) category and a Pointer ID category. For 
each call address within the system which is a test call, 
a pointer to new software is given, while for all call IDs 
containing a normal identification, the pointer is given 
to the old software. The use of such pointers illustrates 
the method by which the system of the present inven- 
tion is able to properly direct both ordinary, live traffic 
and test traffic to the proper version of software. 

While this is the gener^ simplistic interpretation of 
the manner in which the old and new software are 
addressed within the system of the present invention, in 
fact, detailed linked procedure call mechanisms are used 
to create dynamic runtime binding between separately 
loaded program units. That is, when replacing a pro- 
gram unit in the example discussed above, the old and 
the new versions of the software coexist for a time until 
the new version can be verified as correct and activities 
being executed in the old version can be ended as de- 
scribed above. The system of the present invention uses 
trading as a means to access the software through an 
interface via the linked procediue call. In loadtime, all 
interfaces accessible to the linked procedure call are 
published to a trader function in the kemeL Every inter- 
face is published with its identity and an address which 
refers to a method that creates an object from the inter- 
face. The binding between the software versions is 
made in runtime and every time an object is created for 
a specific interface, a request b directed to the trader for 
the address of the create method which is then called 
and returns an object pointer to the created object 

Referring next to FIG. 4 it is illustrated therein that, 
each operation on an object of class X 60 is called indi- 
rectly through the object in the following steps: (1) the 
object pointer 66 addresses the object's data area; (2) at 
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a predefined oSset from the start of the object area the 
address of an operation table 68 can be found 62 (this 
table 68 is common for all objects of one type); and (3) 
the address where the program code of the operation 
starts can be found in the operation table 68 at an ofiTset 5 
corresponding to the operation at choice. Because the 
location of the addresses of the operation tables within 
the objects-data and the order in which the addresses in 
the operation tables are stored are fixed and known, 
operations can be called without assistance from the 10 
trader. One such operation in an interface that can be 
called without the trader is an operation to delete a 
created object 

Use of these operation tables provides the ability to 
achieve polymorphism, a concept that can be imple- 15 
mented using, for example, the programming language 
C-h+and its construct for virtual tables. Polymor- 
phism, meaning "many shapes," is a technique by which 
the behavior of a component that is shared by different 
objects can be changed. In other words, a component 20 
may appear the same in all cases, but may have the 
ability to perform in a somewhat different manner in 
connection with different objects with which it is asso- 
ciated. Polymorphism is useful in allowing the creation 
of families of objects that are related, i.e., they have a 25 
common origin or base, but they perform differently in 
different situations. This allows each object withb a 
family to have methods or functions with identical 
names although the actual code for each object's meth- 
ods may differ vastly. The system of the present inven- 30 
tion utilizes polymorphism, as well as ol^er principles 
of object oriented progranmiing. The system of the 
present invention, however, implements and extends 
the principles in a new and hig^y useful manner, in 
order to achieve dynamic, transparent inter-linking of 35 
different versions of software during execution. 

Referring next to FIG. 5, there is illustrated therein 
the fact that the linked procedure call mechanism used 
in the present invention embodies the concept of a 
trader 80 contained within a kernel 82 which enables an 40 
interfacing relationship between a pair of software units 
84 and 86, containing, respectively, a client class 88 and 
a server class of objects 90. FIG. 5 illustrates in detail 
the steps required in order to create objects within the 
system as shown also in FIG. 4. 45 

Objects are run-time instances of classes that contain 
definitions of both data and functions within a single 
package or unit Because they are able to contain both 
data and code, they act as miniature, independent pro- 
grams. They can be used, therefore, as building blocks 50 
in creating more complex programs without having to 
redevelop the code necessary for those functions. Be- 
cause they can be maintained and modified indepen- 
dently, program maintenance and revision is simplified. 

A class is a template that is used to define an object, 55 
and an object is an instance of a class. A class contains 
two component types, instance variables or data mem- 
bers and methods or member functions. In order to 
support programmers developing programs that play 
the client role within the computer system, a client-class 60 
is automatically generated through the use of an inter- 
face specification. The generated client-class acts as a 
sort of agent for the server-class. The client of the sys- 
tem calls operations from the client-class objects in 
order to ensure that calls are transferred to the software 65 
implementation residing in the server-class. Therefore, 
all code relating to the dynamic binding function is 
found in the client-class. 
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Class declarations control the manner in which the 
compiler will store the addresses in the objects-data and 
in what order the addresses in the operations tables will 
be set forth. Some class declarations are automatically 
generated by the system. When an object is created 
within the system, its "create method" can be located 
through a request to the trader 80 portion of the opera- 
tion system located within the kernel 82. The trader 80 
contains all the interface information for ail by linked 
procedure call accessible classes within the system, i.e., 
it contains information for each object about which 
other objects it is accessible by or to. 

The diagram of FIG. 6 illustrates the way in which a 
process in run-time can be linked by linked procedure 
call to using a new or an old software unit The trader 
80 within the kernel 82 can direct the execution of the 
software unit 100 toward either the old software unit 
102 or the new software unit 104. While making the 
replacement, the server-classes from both the old and 
the new versions each have their interfaces published in 
the trader 80. The trader 80 contains two address entries 
for each item, one for the old software imit 102 and one 
for the new software unit 104. Processes created prior 
to the replacement will continue to use the old software 
unit 102 and its server classes while processes created 
during and after the replacement may be directed to use 
the new software unit 104 and ifs server classes. 

After the replacement has been completed and activi- 
ties within the old software unit 102 have ended, the old 
software unit 102 can be removed &om memory and the 
interfaces published by the server-classes in the old 
software unit 102 may be withdrawn. If an attempt to 
withdraw these server-classes from memory is made 
prior to all processes within the old software imit run- 
ning to completion, the system generates an exception 
call from the kernel 82. An exception hanrfling process 
within the system then allows the non-completed pro- 
cess the opportunity to redirect itself and utilize the new 
software unit 104 or else to terminate. 

The invention uses shared memory for storing the 
executable program code contained in the software 
units which makes it possible for all processes within the 
processors to execute the program code in this shared 
memory. This means that activities within different 
processes within a processor do not have to copy and 
relocate program code when making the dynamic run- 
time binding. The dynamic run-time binding (or linked 
procedure call) is therefore a very fast and real time 
efficient mechanism since no relocation or copying of 
programs is required in run-time. 

One of the advantages of using the trader mechanism 
for dynamic run-time binding is that the software mod- 
ules containing a client part of an interface does not 
have to be modified when the server part contained in 
another software module is changed. That is, no refer- 
ences to the server part have to be changed as long as 
the interface specification is unchanged. 

When defining a unique interface specificatioa in the 
interface description language ELIN, which is de- 
scribed below, a unique number is generated off-line for 
that interface separating it firom all other interfaces. 
This number is used in real time by the server part to 
publish an interface in the trader and by the client part 
at the dynamic run-time binding through the trader 
mechanism. Using this number instead of a string con- 
taining the unique interface name makes the algorithm 
for finding the server part to an interface more real time 
efficient. The algorithm for finding the server part in 
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the trader mechanism can for instance be using hash 
technic or index table, which makes it almost as efficient 
as static binding of code but have the advantage that 
software modules can be changed in a smooth way 
without disturbing ongoing activities using old soft- 
ware. 

In employing the linked procedure call mechanism in 
the present invention, the interface specification is writ- 
ten in an object oriented interface description language 
(ELIN). In this language, there is a special construct 
(ADT) that is specially aimed at the specification of 
linked procedure call interfaces. An ADT in the ELIN 
language is a specification of the interface provided by 
objects of certain types. These objects are well suited to 
be implemented as instances of a class if an object ori- 
ented programming language is employed. The specifi- 
cation of a linked procedure call interface in ELIN 
language comprises the following information: 

(a) a name for the specification; 

(b) other interfaces used as a base for this name; 

(c) one or more constructors (used for creating in- 
stances); and 

(d) zero or more method-specifications, each of 
which consists of a method name, arguments, re- 
turn type and excepti(xis. 

Set forth below, in code, is an example of an interface 
specification that could be used as part of this linked 
procedure call mechanism and that describes an inter- 
face to objects of a type called Stack: 

ADT Stack IS 

BASE 
TelecomObject; 

METHODS 
CONSTRUCTOR (IS size Int); 
push (IN data Int); 
pop ( ) RETURNS Int; 

END ADT Stack; 
©1992 Telcfonaktiebolagct L M Ericsson 

This interface specification defines an ADT named 
Stack, the base ADT being called "TelecomObject" 
Objects of this ADT can accept process or message 
calls from the listed function members. Having a base 
identified for this ADT indicates that there is another 
specification of this type of ADT that is called Teleco- 
mObject That base ADT also has certain specified 45 
methods which the current ADT, as an instance of the 
base ADT will inherit. The function members or meth- 
ods specified in the above ADT definition are in addi- 
tion to those specified in the base ADT. In sum, the 
above code comprises an ADT specification which is SO 
one type of interiface specification that can be created 
within the system. 

An interface can be derived &om another interface 
which then is called the base interface of the derived 
interface. Interfaces can be derived firom more than one 
other interface, with the derived interface inheriting 
firom the operations of each of its base interfaces. The 
derived interface may, in addition, declare its own addi- 
tional operations, although it may not define operations 
having the same name as those inherited from the base 
interfaces. It should be made clear that inheritance only 
affects the interface-level, not the implementation level. 

As shown in FIG. . 7, the system of the present inven- 
tion also includes a stub-code generation tool 112 which 
is used to certify the coordination between the client 65 
and the server which are linked together dynamically in 
runtime through an interface. The interface is specified 
in a language independent fashion, but using the object 
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oriented paradigm. The stub-code generation process 
ensures that a mapping to one of several programming 
languages is achieved and in the following sections, 
there is a brief description of how such a mapping in 
C-f +can be performed. Referring to FIG. 7, there is 
illustrated a way m which an interface specification 110 
employs the stub-generation tool 112 in connection 
with a set of generated files 114 in the system of the 
present invention. FIG. 7 illustrates, in particular, the 
overall structure of the C-f -hmappmg as implemented 
in that language. An interface specification, written in 
the language (ELIN) as used in the system of the pres- 
ent invention, is similar to a class definition used in the 
programming language C-f -h. Likewise, the mecha- 
nism for accessing operations through objects is similar 
to the mann er in which the programming language 
C-h -t- handles virtual functions. Therefore, the mapping 
on C-h +illustrated in FIG. 7 is instructive as to the 
operation of this aspect of the system of the present 
invention. 

The stub-generation tool 112 generates two files for 
both the chent side and the server side, one with the 
suffix h" (header) and one with the suflfix ".cc" 
(code). For the client, the ".h" or header file contains 
two class definitions. One class is an exact copy of the 
corresponding class in the server's ".h" or header file. 
This assures compatibility between the chent and server 
and makes it possible for the client to call objects cre- 
ated by the server. This class' constructor is private, 
however, so that the class cannot be used to create 
automatic objects on the stack. The second class is the 
one to be used at the cUent that acts as an agent through 
which objects created by the server can be accessed. 

For the server side, the corresponding two ".h" 
(header) and **.cc*' (code) files are generated by the 
stub-generation tool 112. The contents Of the ".h" file 
consists of one class definition that will ensure compati- 
bility with the client This is the class that is used as a 
base for implementation. The implementation can be 
based directly on the generated class or the generated 
class can be used as a base from which to derive other 
classes. The ".cc" file contains a skeleton for the 
"crcatemcthod" and a generated table with one entry 
for each Hnked procedure call interface whose create- 
method address should be registered in the trader. The 
body of the createmethod is responsible for creating an 
object that is compatible with the generated class and 
returning a pointer to the newly created object as also 
illustrated in FIG. 4. 

There are several reasons for generating differing yet 
compatible class definitions for the client and server 
sides rather than One shared class definition. First it 
provides different levels of visibihty for members in the 
cUent and the server. For example, a constructor must 
be public in the server but should not necessarily be 
pubUc if it resides in the client. Second, the client and 
server programs can be hnked together for test pur- 
poses without encountering the problem of name colli- 
sions if different classes are used. 

Referring next to FIG. 8, there is shown a certain 
arrangement of charts illustrating certain exemplary 
code blocks and their relationship to one another as 
employed in the system of the present invention. FIG. 8 
illustrates the logical structure of certain generated files 
and written specifications as they might be implemented 
in the system of the present inventioxL At the highest 
level, the Common Interface Specification 120 defines 
an ADT **X" and the methods or operations possible to 
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access for objects of that ADT. Logically subordinate tool providing coordination between said client 

to this ADT, at the next level of definition is a specifica- objects and said server objects. 

tion for a user unit 122 of the Interface Specification 120 4. The method of claim 3 wherein the step of generat- 

and a specification for a provider unit 124 of the Com- ing, with an off-line stub generation tool, both client 

mon Interface Specification 120. The user unit spedfi- 5 objects and server objects from said common interface 

cation 122 defines a client of the common interface, specification includes the steps of: 

ADT X. The provider unit specification 126 defines a generating a file containing at least one client object; 

server of ADT X, and 

At the next logical level below the unit specifications generating a file containing at least one server object. 

122 and 124 are the generated class definitions for users ^- method of claim 4 wherein the step of generat- 

and providers respectively. The generated class defini- ing a file containing at least one client object includes 

tion for XUser 126 illustrates certain user classes de- the step of: 

fined for both public and private use. The generated generating a file containing one client object which is 

class definition for XProvider 128 iQustrates certain compatible with an associated server object in said 

public and private definitions for provider data and generated file containing said server objects, 

functions. ^- The method of claim 2 further comprising the step 

As illustrated above, the system of the present inven- . . 

tion enables the runtime inclusion or linking within a creating said common interfiace specification using an 

process to either new software or old software in a object-oriented interface description language, 

manner that enables software to be both effectively . V^^ method of claim 6 wherein said step of creat- 

tested in real-time as well as to be smoothly and trans- common interface specification fiirther includes 

parentiy substituted in a teleconununications network ^ ^®P^ 

and switching system witiiout disruption of the tele- naming the common interface specification; 

communications traffic within the network. identifying other interfaces used as a base for said 

It is tiius bchcved that die operation and construction common interface specification; 

of tiie present invention will be apparent from the fore- ^reatrng at least one constructor, said constructor 

going description. While die method, apparatus and demonstratmg how to create instances of objects 

system shown and described has been characterized as specifymg said named common mterface spedfica- 

being preferred, it will be readily apparent that various , . ,^ ^ . « 

chang^andmodificationscanl^i^dethereinwithout ^f^? one metiiod-specification for per- 

departing from the spirit and scope of tiie invention as fimctions of said named common interface 

defined^ the foUoiving claims. spcafication, said metiiod-specification mcluding a 

What is claimed is: method name, arguments, return type and excep- 

n^lt.^!"^ ""^^ dyn^caUy Wilding, witMn a com- 35 S^method of claim 6 wherein the step of creating 

pitoigsystemhavmgakeniel,firstand«^^ 3 ^^^^ ^^^^ specification using I object-on^ 

modules respectively contamed withm first and second — .♦-j • *>«c j • \1 v/w|cvi.-vii 

V ^ niuuu in ai^ ouu a«;wuu entcd mtcrface descnption language mcludes the step 

software apphcations, said method comprising the steps ^f. ^ '^^b^ iuwuuw luc atcp 

o i5«i,«j ^^^^^A 11 I. • 1. - creating said common interface specification from a 

proAodmg a hijed procedure call mechanism havmg 40 base mterface, said common interface specification 

«^,^?i^r *^ * -r • J 1 . • . -i* inheriting specified methods of said base interface, 

providing a chent mterface said chent mterface capa- 9. method of claim 2 fiirther comprising the step 

ble of accessmg said trader portion; Qf. f & y 

providmg a server interface, said server interface creating said common interface specification in a 

;n^^ ^""^^^ ^^T' ^ « computer program language-independent fashion 

m^g said chent mterface mto said first software ^sing an object oriented paradigm!^ 

module; . ^ . lO.Themethodof claim 9 wherein the step of pro vid- 

msertmg ^d server mterface mto said second soft- i^g a cHent interface includes tiie step of: 

. ^ ^1 module; providing a client object, said dient object capable of 

identifymg said chent mterfece by executing said first 50 accessing said trader portion. 

software module; xhe metiiod of claim 9 fiirther comprising tiie step 

laentiiying said server interface by accessing said of: 

trader portion with said identified client interface; inserting said server interface*s location into said 

. trader portion, 
substitutmg said server interface in place of said iden- 55 12. The metiiod of claim 9 wherein tiie step of provid- 

tified chent interface, during execution of said first ing a server interface includes the step of: 

«)ftware module, thereby dynamically binding said providing a server object, said server object capable 

first and second software modules. of accessing said trader portion. 

2. The method of claim 1 fiirther comprising the step 13. The method of claim 12 fiirther comprising die 
of- ^ , 60 steps of: 

generating said client mterface and said server inter- loading, into said computing system, a third software 

face from a common interface specification. appUcation containing a third software module, 

3. The method of claim 2 wherein the step of generat- said third software modxile including server objects 
ing said client interface and said server interface ft-om a which are compatible with said server objects in- 
common mterface specification includes the step of: 65 serted into said second software module; and 

generating, with an off-line stub generation tool, both inserting the location of said server objects contained 

client objects and server objects from said common within said third software module into said trader 

interface specification, said off-line stub generation portion. 
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14. The method of claim 13 further comprising the 
step of: 

directing a process, created prior to loading said third 
software module, to said second software module 
by accessing said trader portion with said kernel. 5 

15. The method of claim 13 further comprising the 
step of: 

directing a process, created subsequent to loading 
said third software module, to said third software 
module by accessing said trader portion with said 10 
kernel. 

16. A method of dynamically binding, within a com- 
puting system having a shared memory and a kernel, 
first and second software modules respectively con- 
tained within first and second software applications, 
said method comprising the steps of: 

providing a linked procedure call mechanism having 
a trader portion; 

loading said fixsi software module into said shared 
memory of said computing system, said first soft- 
ware module including a client interface; 

loading said second software module into said shared 
memory of said computing system, said second 
software module induding a server interface; 

inserting into said trader portion a memory address of 
said server interface 

identifying said client interface by executing said first 
software module; 

identifying said server interface by accessing said 
trader portion with said identified client interface; 
and 

substituting said server interface by accessing said 
trader client interface, during execution of said first 
software module, thereby dynamically binding said 3 ^ 
first and second software modules. 

17. The method of claim 16 further comprising the 
steps of: 

loading a plurality of software modules into said 
shared memory of said computing system, each of 40 
said plurality of software modules including an 
associated cHent inter£ace; and 

substituting said server interface in place of each of 
said associated client interfaces bdng executed. 

18. The method of claim 17 further comprising the 45 
steps of: 

inserting a plurality of server interfaces into said first 

software module; 
inserting a plurality of client interfaces compatible 

with said plurality of server interfaces into said 50 

second software module; and 
inserting the address of each of said plurality of 

server interfaces into said trader portion. 

19. The method of claim 18 further comprising the 
step of: 55 

generating a unique number which identifies both 
said client interface and said server interface. 

20. The method of claim 19 further comprising the 
steps of: 

inserting said generated unique number into said 60 

trader portion; and 
inserting said server interface's memory address into 

said trader portion. 

21. An Apparatus for dynamically binding, within a 
computing system having a kernel, first and second 65 
software modules respectively contained within first 
and second software applications, said Apparatus com- 
prising: 



means for providing a linked procedure call mecha- 
nism having a trader portion; 

means for providing a client interface, said client 
interface capable of accessing said trader portion; 

means for providing a server interface, said server 
interface capable of accessing said trader portion; 

means for inserting said client interface into said first 
software module; 

means for inserting said server interface into said 
second software module; 

means for identifying said client interface by execut- 
ing said first software module; 

means for identifying said server interface by access- 
ing said trader portion with said identified client 
interface; and 

means for substituting said server interface ia place of 
said identified client interface, during execution of 
said first software module, thereby dynamically 
binding said first and second software modules. 

22. The Apparatus of claim 21 further comprising: 
means for generating said client interface and said 

server interface from a common interface specifica- 
tion. 

23. The Apparatus of claim 22 wherein the means for 
generating said client mterface and said server interface 
from a common interface specification includes: 

means for generating, with an offline stub generation 
tool, both client objects and server objects from 
said common interface specification, said off-line 
stub generation tool providing coordination be- 
tween said client objects and said server objects. 

24. The Apparatus of claim 23 wherein the means for 
generating, with an off-line stub generation tool, both 
client objects and server objects from said common 
interface specification includes: 

means for generating a file containing at least one 

client object; and 
means for generating a file containing at least one 

server object. 

25. The Apparatus of claim 24 wherein the means for 
generating a file containing at least one client object 
includes: 

means for generating a file containing one client ob- 
ject which is compatible with an associated server 
object in said generated file for said server objects. 

26. The Apparatus of claim 22 further comprising: 
means for creating said common interface specifica- 
tion using an object-oriented interface description 
language. 

27. The Apparatus of claim 26 wherein said means for 
creating said common interface specification further 
includes: 

a name for the common interface specification; 

means for identifying other interfaces used as a base 
for said named common interface specification; 

means for creating at least one constructor, said con- 
structor demonstrating how to create instances of 
objects specifying said named common interface 
specification; and 

means for creating at least one method-specification 
for performing functions of said named common 
interface specification, said method-specification 
including a method name, arguments, return type 
and exceptions. 

28. The Apparatus of claim 26 wherein the means for 
creating a common interface specification using an ob- 
ject-oriented interface description language includes: 
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means for creating said common interface specifica- 
tion from a base interface, said common interface 
specificatioii inheriting specified methods of said 
base interface. 

29. The Apparatus of claim 22 fiirther comprising: 
means for creating said common interface specifica- 
tion in a computer program language-independent 
fashion using an object oriented paradigm. 

30. The Apparatus of claim 21 wherein the means for 
providing a client interface includes: 

means for providing a client object, said client object 
capable of accessing said trader portion. 

31. The Apparatus of claim 21 further comprising: 
means for inserting said server interface's location 

into said trader portion. 

32. The Apparatus of claim 21 wherein the means for 
providing a server interface includes: 

means for providing a server object, said server ob- 
ject capable of accessing said trader portion. 

33. The Apparatus of claim 32 further comprising: 
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means for loading, into said computing system, a 
third software application containing a third soft- 
ware module, said third software module including 
server objects which are compatible with said 
server objects inserted into said second software 
module; and 

means for inserting the location of said server objects 
contained within said third software module into 
said trader portion. 

34. The Apparatus of claim 33 further comprising: 
means for directing a process, created prior to load- 
ing said third software module, to said second soft- 
ware module by accessing said trader portion with 
said kernel. 

35. The Apparatus of claim 33 further comprising: 
means for directing a process, created subsequent to 

loading said third software module, to said third 
software module by accessing said trader portion 
with said kernel. 
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